1. Field of the Invention
The present invention relates in general to a design structure, and more specifically to a design structure for piggybacking multiple data tenures on a single data bus grant to achieve higher bus utilization.
2. Description of the Related Art
In computer architecture, a bus is a collection of related signal lines that transfer information (e.g. addresses and data) between components of a computer system. Unlike a point-to-point connection, a bus can logically connect several devices over the same set of signal lines. Typically, a computer system will have separate buses for transmitting different types of signals. A control bus carries commands from master devices and returns status signals from slave devices. A data bus is used to read data from and write data to another device on the bus. An address bus is used for communicating the physical addresses of computer memory elements and locations which the requesting device (master) wants to access. Access to a bus is controlled by a bus arbiter executing a bus protocol. A device submits a request to access the bus. When the bus arbiter grants the request, the requesting device may begin receiving data from the bus or writing data to the bus. Some architectures have a single arbiter with which a master arbitrates for the control bus, the address bus and
The normal data flow for a read request is as follows. The master issues a read request which is accepted and queued by a slave. When the slave has some or all of the data ready to return, the slave requests access to the read data bus. When the slave receives the grant for the read data bus, the slave returns the data for that transaction. Alternatively, the slave may return part of the data for that transaction and then request the data bus again to return more (or the rest) of the data for that transaction.
For a bus operating at high frequencies (e.g., 400 MHz and greater), the best turnaround time that can easily be achieved between a data bus request and a data bus grant (without a custom solution) is typically two clock cycles. In other words, if a device asserts a request on clock i, the earliest the device can expect a grant is on clock i+2. This delay occurs because the request and the grant must be “latched” into and out of an arbiter at those frequencies and each latching event takes one clock. Since the grant signal must be latched into the device providing the data, it then follows that the earliest the device can begin driving data on the bus is on clock i+3. This cadence allows efficient use of the data bus, provided that data bus tenures are three or more beats in length. A data bus tenure (“data tenure”) is the signaling with which a device writes data to the data bus in response to a granted bus request. As long as a request is made for the next transaction while there are three or more beats of data remaining to be delivered on the current transaction, a grant can be provided on the last beat of the current transaction, allowing that device to start driving its data on the next clock. There will be no gaps or stalls on the data bus, allowing the bandwidth of the bus to be fully utilized. However, when multiple transactions in a row are returned with data tenures that are only one or two beats, the bandwidth of the data bus will not be fully utilized. There will be gaps in data transmission as the bus is idle awaiting the next grant. This reduces the overall efficiency of the data bus.